For further reference, see also toolbox/FAQs/SGIfaqs/Dwarf-faq, and the IRIX 6.2-based libdwarf src directory in toolbox/src/swtools/libdwarf.
DWARF is a binary debugging-information-format. It defines, in detail, a way for compilers to tell debuggers about source programs.
DWARF1 is the DWARF produced by USL's SVR4 compilers and used by their debuggers. It is no more capable than the MIPS mdebug symbol table and is less dense than mdebug. We will not use DWARF1.
SGI will be using DWARF 2. It is capable of recording much more detailed information than DWARF 1 and is far more compact (debugging information in DWARF2 format takes much less space on disk than debugging information in DWARF1 format).
compiler_dev.src.dwarf subsystem.
FOREWARD
This document specifies the second generation of symbolc debugging information based on the DWARF format that has been developed by the UNIX International Programming Languages Special Interest Group (SIG). It is being circulated for industry review. The first version of the DWARF specification was published by UNIX International in January, 1992. The current version adds significant new functionality, but its main thrust is to acheive a much denser encoding the DWARF information. Because of the new encoding, DWARF version 2 is not binary compatible with DWARF version 1.
As this point, the SIG believes that this document sufficiently supports the debugging needs of C, C++, FORTRAN 77, Fortran90, Modula2, and Pascal, and we have released it for public comment. We will accept comments on this document until September 30, 1994. Comments may be directed via email to the SIG mailing list (plsig@ui.org). If you are unable to send email, paper mail, FAX, or machine readable copy on UNIX, MS-DOS, or Macintosh compatible media can be sent to UNIX International at the address listed below, and wil be forwarded to the SIG.
ABSTRACT:
This document describes an interface to a library of functions to access DWARF debugging information entries and DWARF line number information. It does not make recommendations as to how the functions described in this document should be implemented nor does it suggest possible optimizations.
The document is oriented to reading DWARF version 2. There are certain sections which are SGI-specific (those are clearly indentified in the document). We intend to propose this to the PLSIG committee as the basis for a standard libdwarf interface.
The proposals made in this document are subject to change.
47 pages
NOTE: CONTENTS is on page 45
17 pages
NOTE: CONTENTS is on page 16
from the toolbox/FAQs/SGIfaqs/Dwarf-faq file:
The documents mentioned in section 3 are long on details and short on overview. Lets try to put this all in to a total picture.
To represent Debugging Information in an a.out we need several quite different categories of information spread across various ELF object file sections.
A. Information about code and data variables.
DWARF information is a tree of Debugging Information
Entries (DIEs). Each tree entry (Die) has a TAG which
identifies what type of entry it is and Attributes
which give the details. DIEs at the global level in a
compilation unit are tied together with Sibling Pointers.
Siblings are equal-level DIEs.
Children, on the other hand, are *owned* DIEs.
Lets adopt the following symbols for DIE relationships:
Sibling pointer ->
Child pointer |
v
Here is a representation of the DIEs for t.c where types
are left out to keep things simple (they don't change
this, they are just more DIEs to clutter things up):
t.c:
int foo(int i, int j) { return 3;}
int goo;
Compilation_Unit
|
v
function "foo" -> global variable "goo "
|
v
parameter "i" -> parameter "j"
This goes in the .debug_info section with a tiny amount
of supporting data in .debug_abbrev
B. Information about the mapping from code addresses to source
A separate section holds a very compact mapping from
code addresses to source lines (and columns).
This is in the .debug_line section.
C. Information about C Macros
If desired, all C Macro #defines and #undef-s and
#includes are recorded, with
the mapping back to the source files.
This is in the .debug_macinfo section.
D. Information about unwinding stack frames
This is specially recorded in a section of its own: a
seperate small string of bytes per function/procedure.
This is in the .debug_frame section.
Other .debug_* sections are for supporting data or for fast access to
global names, types, and statics.
OR, ...